ptrace: Fix ->ptracer_cred handling for PTRACE_TRACEME
authorJann Horn <jannh@google.com>
Thu, 4 Jul 2019 15:32:23 +0000 (17:32 +0200)
committerSalvatore Bonaccorso <carnil@debian.org>
Thu, 18 Jul 2019 22:23:17 +0000 (23:23 +0100)
commit89e62b335b62e1c9e78b461f2af65edd829d57c4
tree0da03b554aafb38bbde7c88c28846b89dd5823fd
parentceb534ae7dd5a947e730e769f3fc3f3be54d416f
ptrace: Fix ->ptracer_cred handling for PTRACE_TRACEME

Fix two issues:

When called for PTRACE_TRACEME, ptrace_link() would obtain an RCU
reference to the parent's objective credentials, then give that pointer
to get_cred().  However, the object lifetime rules for things like
struct cred do not permit unconditionally turning an RCU reference into
a stable reference.

PTRACE_TRACEME records the parent's credentials as if the parent was
acting as the subject, but that's not the case.  If a malicious
unprivileged child uses PTRACE_TRACEME and the parent is privileged, and
at a later point, the parent process becomes attacker-controlled
(because it drops privileges and calls execve()), the attacker ends up
with control over two processes with a privileged ptrace relationship,
which can be abused to ptrace a suid binary and obtain root privileges.

Fix both of these by always recording the credentials of the process
that is requesting the creation of the ptrace relationship:
current_cred() can't change under us, and current is the proper subject
for access control.

This change is theoretically userspace-visible, but I am not aware of
any code that it will actually break.

Fixes: 64b875f7ac8a ("ptrace: Capture the ptracer's creds not PT_PTRACE_CAP")
Signed-off-by: Jann Horn <jannh@google.com>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name ptrace-Fix-ptracer_cred-handling-for-PTRACE_TRACEME.patch
kernel/ptrace.c